Frequently, a single web page will contain numerous components, with different types of information in each of the components. For example, a web page for a particular stock may contain a table with the stock's current price, a graph of the stock's previous prices, and news for the company selling the stock. Frequently, the components of a web page are generated by services provided by parties other than the party that designs the web page. For example, the service of generating current stock price tables may be provided by one third party, and the service of generating the graph of stock prices may be provided by yet another third party.
The code used to provide services that generate web page components is referred to as a “portlet”. The party that designs a portlet is referred to herein as the portlet developer. To add value to their services, portlet developers frequently design their portlets to include tools that allow users to customize the components that are generated by their portlets. For example, the provider of a portlet that generates the current stock price table may provide a tool that allows the user to perform customizations, such as changing the stock for which price information is displayed, changing the color of the chart, changing the size of the chart, etc.
Page designers decide how pages will look and what information is to be displayed on the pages. The page designers select the best portlets to build the type of page they desire. However, the page designers are dependent on portlet developers to create portlets that have the characteristics the page designers need. Further, the portlets used in building a particular page may be developed by many different portlet developers residing in many different locations, and may be developed across a large time span.
The fact that a web page includes components generated by portlets provided by third parties may have a detrimental effect on the experience of the web page user. For example, assume that a user wants to see stock information for a different stock than is currently displayed on a web page. Because the portlets are provided by different parties, the web page user would typically have to separately customize each component on the web page using whatever customization tool that is built into the corresponding portlet.
This approach has numerous disadvantages. Not only does this approach require the user to individually customize each portlet (referred to hereinafter as “portlet level customization”) on the web page, but this approach also requires the user to know how to customize the portlets. The process of customizing the portlets may be confusing to a user because the user interface provided for portlet customization may differ for each of the various components on the web page.
Further, this approach has disadvantages for the page designers and for the portlet developers. Specifically, while the web page designer would typically prefer to have more control over the user-specific customization of the web pages that they are designing, the user-specific customization of components is handled by the portlets. On the other hand, portlet designers would generally prefer not to have the responsibility of managing all of the user-specific customizations of the components their portlet is generating.
Typically, when a user specifies a customization using a portlet's customization tool, the customization is stored so that, in future requests by the same user, the component generated by the portlet will continue to reflect the customization. However, some portlets are designed to handle “one-time” customizations that are specified in the URL associated with the portlet. Specifically, one or more parameter values may be appended to a URL that requests a service provided by a portlet. The URL may be parsed by a portlet to extract the parameter values, and the portlet may generate a component that is customized based on the parameter values thus extracted. However, this approach requires the portlets to parse the URL for parameters. Not only is parsing the user-specified URL cumbersome, but this approach incurs the same disadvantages already described in building portlets. Further, this approach requires a user to re-enter the same customized URL every time the user wants to see the same customized component.
Frequently web pages have links to other web pages. When users manipulate a user interface object that corresponds to a link, a request is sent to retrieve the web page specified in the link. These links are static in that the URL of the particular web page to which they correspond is hard-coded into the link.
Components that are generated by portlets may also include static links. For example, a web page used for tracking software bugs may contain a portlet with a list of static links, where each static link corresponds to a web page describing a particular bug. A page designer may want a portlet with similar capabilities, but where the portlet would display a different set of bugs, or even bugs for a different product. However, since the links are static and hard-coded into the portlet, a portlet developer would have to develop a new portlet to address the needs of the page designer.
Typically, when a user interacts with a component on a page, where the component is provided by a third-party portlet, the response to the interaction is determined entirely by the portlet. Under many circumstances, a page designer would prefer to have more control over the user experience, including having the ability to specify how the web page responds to user interactions with components provided by third-party portlets.
As it can be seen, there is a need to facilitate user-customization of web pages that include components generated by portlets. In addition, there is a need to allow a designer of a web page to specify actions that will be performed in response to user interaction with components, designed by third-parties, that are included in the web page.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.